Methods, apparatus and computer programs for processing alerts and auditing in a publish/subscribe system

ABSTRACT

A message broker receives a published message from a publisher program. Responsive to identification of one or more subscriber programs subscribing to messages of the type of the received message, the broker forwards the received message to the one or more subscriber programs. Matcher components compares the received message with stored subscriptions to identify subscriber programs, generates an alert when an alert condition is satisfied, and compares the generated alert with stored subscriptions to identify subscriber programs subscribing to the alert. The alert is then forwarded to the subscriber program subscribing to the alert.

FIELD OF INVENTION

The present invention relates to communications within a network, and inparticular to methods and apparatus for publish/subscribe datacommunications.

BACKGROUND

Within a message delivery system, messages may be delivered through anetwork of servers including one or more “brokers” which provide routingand formatting services. The brokers are located at communication hubswithin the network.

Many message brokers support the publish/subscribe communicationparadigm. This involves a set of one or more publishers sendingcommunications to be received by a set of one or more subscribers whohave registered their interest in receiving communications of that type.Publish/subscribe allows subscribing users to receive the very latestinformation in an area of interest (for example, stock prices or eventssuch as news flashes or store special offers). A typicalpublish/subscribe environment has a number of publisher applicationssending messages via a broker to a number (potentially a very largenumber) of subscriber applications located on remote computers acrossthe network. In this case, the subscribers notify the broker(s) of themessage types they wish to receive and this information is stored at thebroker. Publishers send their messages to the broker, which uses amatching engine to compare the message type (for example, checkingmessage header topic fields and/or checking message content) with itsstored subscriber information to determine which subscribers the messageshould be forwarded to. The message broker may perform additionalfunctions, such as filtering, formatting or otherwise processingreceived messages before forwarding them to subscribers.

A commercially available example of a message broker supporting thepublish/subscribe paradigm is IBM Corporation's WebSphere MQ Integratormiddleware product family. (IBM and WebSphere are trademarks ofInternational Business Machines Corporation).

Existing publish/subscribe solutions (including IBM's WebSphere MQIntegrator products) provide a security authorization feature thatpermits publications to be accepted or refused by reference to thespecific publisher and topic, and permits their dissemination to becontrolled by reference to the set of subscribers authorized to receivemessages for that topic. Such authorizations will be set up by anadministrator and act in conjunction with the topic subscriptions madeby the subscribers themselves.

U.S. Pat. No. 6,158,007 discloses a broker enforcing security policiesfor different subjects, and an audit service subscribing to apublish/subscribe matching engine to receive messages on specificsubjects. The audit service can be thought of as one of the subscribers,since the audit service will receive the original message if the messagesubject matches a specific list of subjects stored at the broker. Aproblem with this approach is that the publish/subscribe paradigmnormally only allows a subscriber to receive a message which matches itssubscription profile, without knowing which other subscribers receivedthe message.

Infosafe from icc.net is a publishing management service which keeps anaudit trail for publish/subscribe activity—including a complete audittrail of all product based activity and reports of all upload anddownload activity by client and product.

David Arnold et al, “Discourse with Disposable Computers: How and WhyYou Will Talk to Your Tomatoes”, USENIX Proceedings of the EmbeddedSystems Workshop, Mar. 29-31 1999, Cambridge, Mass., USA, describes aprototype message routing program, known as Elvin, which providescontent-based routing and security based on authorization keys. Arnoldet al recognize the need for charging for publish/subscribe services,but the only solution mentioned is charging based on the number of bytesof data exchanged.

There remains a need in the art for improved publish/subscribe systems,in which features such as auditing, charging and/or security are notlimited as in the above-referenced examples.

SUMMARY OF INVENTION

Aspects of the present invention provide methods, data processingsystems and computer programs for generating alerts in response toevents within a publish/subscribe communications system. The alerts aregenerated by a matching engine of the publish/subscribe system, and thealerts are then processed by a matching engine within thepublish/subscribe system to determine required dissemination of alertinformation.

Alerts in this context comprise indications of the occurrence ofpredefined alert conditions. In general, the alert conditions will bespecific trigger events such as an attempt by a publisher to publish onan unauthorized topic or other attempts to perform actions blocked byaccess control lists (ACLs), attempts to access sensitive documents(even if permitted), or all accesses to information for which an audittrail or use-based charging is required. The alerts may drive a chargingprocess.

According to a first aspect of the invention, there is provided a methodfor processing messages in a publish/subscribe message disseminationsystem, wherein one or more alert conditions are defined for the system,the method comprising the steps of: receiving a message; comparing themessage with stored message subscriptions to determine requireddissemination of the message; generating an alert when an alertcondition is satisfied; comparing the alert with stored alertsubscriptions to determine required dissemination of the alert; andcontrolling dissemination of the message and the alert in accordancewith their respective required dissemination.

Preferably, the step of comparing the message with stored messagesubscriptions includes comparing with stored authorization information.The message and alert subscriptions and authorization information arepreferably stored in association with message topics. Example alertconditions are identification of a subscription topic match for whichthe subscriber should be charged or for which auditing is required.

Additional aspects of the invention provide a message broker system anda data processing apparatus for providing a publish/subscribe messagedissemination service on behalf of publisher and subscriber programs.The apparatus or system receives a published message from a publisherprogram and, responsive to identification of one or more subscriberprograms subscribing to messages of the type of the received message,forwards the received message to the one or more message subscriberprograms. One or more matcher components of the system or apparatuscompares the received message with stored message subscriptions toidentify the one or more subscriber programs, generates an alert when analert condition is satisfied, and compares the generated alert withstored alert subscriptions to identify one or more subscriber programssubscribing to the alert. The alert is then forwarded to the subscriberprogram subscribing to the alert.

U.S. Pat. No. 6,158,007 (referenced above) does not generate alerts butonly routes the original message to an audit service, and so there is nodisclosure in U.S. Pat. No. 6,158,007 of feeding an alert into apublish/subscribe matching engine to determine its requireddissemination.

Additionally, existing data processing systems which generate alerts inresponse to trigger events typically forward all alerts to a predefinedapplication or person, typically identified by a network addressprovided to the mechanism which generates the alert, without feeding thealerts into a publish/subscribe matching engine.

The present invention provides great flexibility in relation to onwarddissemination and/or processing of alert information, and in preferredembodiments this can be achieved efficiently since all or most of theprocessing by the publish/subscribe matching engine which determineswhen to generate an alert is already being performed for publisher/topicand subscriber/topic matching. In preferred embodiments, the samematching engine then performs additional processing to determine whatdissemination or additional processing of the alert is required.

Thus, solutions according to the preferred embodiment are able to reusematching program code for dissemination and processing of alerts and canuse an individual execution of that program code both forpublish/subscribe matching and alert generation.

Methods according to the invention may be implemented by means of acomputer program product comprising program code recorded on amachine-readable recording medium, for controlling the performance ofoperations of the data processing apparatus on which the program codeexecutes. Such a program product may be a messaging middleware programincluding a publish/subscribe matching component.

BRIEF DESCRIPTION OF DRAWINGS

Preferred embodiments of the invention are described hereafter, by wayof example, with reference to the accompanying drawings in which:

FIG. 1 is a schematic representation of a messaging network in whichpublisher and subscriber applications communicate via a message broker,and in which the present invention may be implemented;

FIG. 2 shows an example topic tree for use as a searchable index withinthe message broker, with associated stored objects representedschematically;

FIG. 3A is a schematic flow diagram showing a sequence of steps of amethod of processing a received message;

FIG. 3B shows the method steps of FIG. 3A and additional steps ofgenerating and processing alerts using subscription matching, accordingto an embodiment of the invention;

FIG. 4 shows a second example topic tree and example storedsubscriptions and subscriber access controls;

FIG. 5 shows the fields of an example alert message generated within amessage broker according to an embodiment of the invention;

FIG. 6 shows the topic tree of FIG. 4 including a stored rule forgenerating an alert in response to an ACL rejection, according to anembodiment of the invention; and

FIG. 7 shows the topic tree of FIG. 6 including a stored rule forgenerating alerts for sent messages, according to an embodiment of theinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

A first embodiment of the invention provides a mechanism for improvedauditing of publications and dissemination of audit information in apublish/subscribe system. The audit information may be used to drive acharging process for accounting for service usage in a publish/subscribeenvironment or for improved security management.

The publish/subscribe paradigm was described earlier. Before describingembodiments of the present invention in more detail, a brief descriptionof message queuing and message brokers will be helpful.

Messaging and Message Brokers

IBM Corporation's MQSeries and WebSphereMQ family of messaging productsare examples of known products which support interoperation betweenapplication programs running on different systems in a distributedheterogeneous environment. Message queuing and commercially availablemessage queuing products are described in “Messaging and Queuing Usingthe MQI”, B. Blakeley, H. Harris & R. Lewis, McGraw-Hill, 1994, and inthe following publications which are available from IBM Corporation: “AnIntroduction to Messaging and Queuing” (IBM Document numberGC33-0805-00) and “MQSeries—Message Queue Interface Technical Reference”(IBM Document number SC33-0850-01). The network via which the computerscommunicate using message queuing may be the Internet, an intranet, orany computer network. MQSeries is a trademark of IBM Corporation.

IBM's WebSphere MQ messaging products provide transactional messagingsupport, synchronising messages within logical units of work inaccordance with a messaging protocol which gives assured once andonce-only message delivery even in the event of system or communicationsfailures. IBM's WebSphereMQ products provide assured delivery by notfinally deleting a message from storage on a sender system until it isconfirmed as safely stored by a receiver system, and by use ofsophisticated recovery facilities. Prior to commitment of transfer ofthe message upon confirmation of successful storage, both the deletionof the message from storage at the sender system and insertion intostorage at the receiver system are kept ‘in doubt’ and can be backed outatomically in the event of a failure. This message transmission protocoland the associated transactional concepts and recovery facilities aredescribed in international patent application WO 95/10805 and U.S. Pat.No. 5,465,328.

The message queuing inter-program communication support provided byIBM's WebSphere MQ products enables each application program to sendmessages to the input queue of any other target application program andeach target application can asynchronously take these messages from itsinput queue for processing. This achieves delivery of messages betweenapplication programs which may be spread across a distributedheterogeneous computer network, without requiring a dedicated logicalend-to-end connection between the application programs, but there can begreat complexity in the map of possible interconnections between theapplication programs.

This complexity can be greatly simplified by including within thenetwork architecture a communications hub to which other systemsconnect, instead of having direct connections between all systems.Message brokering capabilities can then be provided at thecommunications hub to provide intelligent message routing andintegration of applications. Message brokering functions typicallyinclude the ability to route messages intelligently according tobusiness rules and knowledge of different application programsinformation requirements, using message ‘topic’ information contained inmessage headers, and the ability to transform message formats usingknowledge of the message format requirements of target applications orsystems to reconcile differences between systems and applications.

Such brokering capabilities are provided, for example, by IBMCorporation's MQSeries Integrator and WebSphere MQ Integrator products,providing intelligent routing and transformation services for messageswhich are exchanged between application programs using IBM's MQSeriesand WebSphere MQ messaging products. Such message broker capabilitiescould be integrated within other components of a data processing system,such as within the operating system software.

A multi-broker topology may be used to distribute load across processes,machines and geographical locations. When there are a very large numberof clients, it can be particularly beneficial to distribute thoseclients across several brokers to reduce the resource requirements ofthe brokers, and to reduce the impact of a particular server failing.The scalability and failure tolerance of such multi-broker solutionsenable messages to be delivered with acceptable performance when thereis a high message throughput or a broker fails. When clients aregeographically separated, it can be beneficial to have brokers locatedlocal to groups of clients so that the links between the geographicallocations are consolidated, and for well designed topic trees (seebelow) this can result in many messages not having to be sent to remotelocations.

FIG. 1 shows an example message broker network in which one or manypublisher applications 10 are sending 110 messages to a first messagebroker 20. The first message broker may have one or many subscriberapplications 30 which have registered 100 their interest in receivingspecified message types from the publishers. In a typicalpublish/subscribe message broker environment, the publisher does notexplicitly identify target subscribers and may not know or care who thesubscribers are. Publisher and subscriber applications do not have adedicated end-to-end connection, and may not even be concurrentlyconnected to the broker network.

Instead, publishers typically specify 110 topic names for the messagesthey are publishing, and subscribers specify 100 topic names for themessages they are interested in receiving. The message broker includes amatching engine 60 for comparing an incoming message with thesubscription profiles 40 of the various subscribers to identify matches,and the broker passes matching messages to an output component forforwarding to the relevant subscribers. For example, a subscriber S1 maybe interested in receiving all messages related to the IBM stock priceand may send a subscription request to the broker such as “Stock/IBM”.The broker stores this subscription information. Then if a messagearrives at the broker from a publisher and the message header includestopic identifiers “Stock/IBM” the broker will compare this message withits subscription lists, identify that the message matches thesubscription profile for subscriber S1 and route the message to S1.

Other message broker solutions enable content-based routing of messages(i.e. the analysis of a message by the broker is not limited to thetopic information in message headers). For a topic such as “Stock/IBM”,a content filter “Body. price>100” could also be used to only identify amatch for published messages in which the stock price exceeds thespecified value. Stock price examples will be referred to again later inthe context of example applications of alerts.

Typical message broker solutions use a single transport mechanism forall messages. For example, a message broker may be configured to alwayssend messages with transactional assured delivery under the control ofIBM Corporation's WebSphere MQ message delivery software. However, theuse of different communication protocols for different message types hasrecently been proposed.

Referring to FIG. 1, publishers 10 create messages containing a topicname. The published messages are delivered 110 to a connected messagebroker 20. Subscribers 30 create subscriptions 40 containing a topicattribute and, optionally, a content filter for that topic. Thesesubscriptions are registered 100 with the message broker, which storesthem in a table format in a repository 50. Efficient access to relevantsubscription information and other data within the tables is enabled bystoring the data in a ‘match space’ storage area of the repository inassociation with topic names, and organizing the topic names in a treestructure. The topic tree is a form of searchable index for identifyingrelevant data objects in the repository, and its organization reflectsthe normal ordering of topic names within topic strings of publishedmessages and received subscriptions. An example topic tree is shown inFIG. 2.

The tables may include filters for any number of the topics of interestfor any of the subscribers 30 that connect to the broker network viaconnections to that broker 20. A single subscriber 30 may registermultiple subscriptions 40 with different filters for different topics.

Described below with reference to FIG. 3A is a sequence of stepsperformed by a message broker when processing received messages.

When the message broker 20 receives 300 a published message, a firststep performed by the broker is to search 310 the match space of therepository 50 to identify stored topics and other attributes or objectswhich match the message information, and to retrieve the relevantinformation and objects. The topic name within the published message isa key parameter for this search and retrieval. The traversal may involvea full traversal of the repository ‘match space’ in which subscriptions(and other information such as authorization information) are stored asobjects.

An efficient mechanism for storing authorization information is to storeaccess control lists (ACLs) in association with the topics in the topictree mentioned earlier.

FIG. 2 shows a simple example of a topic hierarchy for publishedmessages and subscriptions. Some of the topics have subscription listobjects (210, 230) and ACL objects (220, 240) stored against them. Letus assume that a message with topic string‘BigCorp/BusinessUpdate/Sales’ is received by the broker. The scanningof the repository's match space is performed iteratively using thecomponents of the topic string and the stored topic tree. Firstly, thetopic component ‘BigCorp’ is used to identify a relevant topic hierarchy200 within the match space; then the ‘BusinessUpdate’ component iscompared with the topic tree to identify stored objects includingsubscription lists 210 and ACL objects 220 (and potentially other storedobjects); and then the ‘Sales’ component of the received topic string isused to identify further subscription list objects 230 and ACL objects240.

All of the relevant information identified in this search is thenconsolidated 320 and the accumulated ACLs are combined, with allowancefor ACL inheritance, and the result of this processing is output as aSearchResults object for further processing.

A next step is to process the SearchResults object to check 330 whetherthe SearchResults object contains a publisher ACL object for the topicof the received message. This determines whether the publisher isauthorized to publish messages on the specific topic. For example, amessage broker may be set up to ensure that certain topics ofinformation are only accepted from specific approved sources (such as anews service trusted for accurate and politically-unbiased reporting, ora source of photographic images known for high quality and originality).Any attempt by an unauthorized party to publish information on thattopic will be blocked—the broker will reject the message.

A next step performed by the broker is to process the subscription listswithin the SearchResults object to identify the set of subscribersrelevant to the topic string of the received message. As noted earlier,subscriptions may contain a filtering expression on elements of themessage body and the matching component 60 applies these filters toidentify matches when the filter as well as the topic name is satisfied.

For each subscriber 30 having a registered subscription 40 which matchesthe message, the message broker 20 also checks 350 anadministrator-defined authorization policy for the message topic and thesubscriber which registered the subscription.

Since the ACLs are stored in association with topics in the same way assubscription lists, the checking of authorizations can be performed bycomparing topic and subscriber names with the consolidated ACLs withinthe SearchResults object—similarly to comparing topics with embeddedsubscription list objects. The set of matching subscriptions are alsoprocessed to remove duplicates. The original scan of the subscribermatch space retrieved all of the information required to checksubscription lists and ACLs.

An identified match between a subscriber and the topic of a receivedmessage will not result in the message being forwarded to thatsubscriber if blocked by an ACL. However, subject to the authorizationcheck, the message broker then delivers 360 the message to each matchingsubscriber which satisfies the authorization check.

A specific example will now be described with reference to the topictree 400 of FIG. 4. The annotations of the form [Sa] indicate thatsubscriber a has subscribed to that part of the tree. The annotations ofthe form (b) indicate that the access control list for the current topic(and for the underlying topics in that part of the tree in the absenceof conflicting underlying ACLs—in view of ACL inheritance) comprisessubscriber b.

Assume the following subscriptions have been received by the broker:

-   [Sa]: BigCorp/*-   [Sb]: BigCorp/stock/*-   [Sc]: BigCorp/announcement/*-   [Sd]: BigCorp/stock/sell/*    Assume the following subscriber access controls have been defined:-   {a}: *-   {a}: ! BigCorp/stock (! used to indicate NOT)-   {b}: BigCorp/*-   {c}: *    Assume that the default in the absence of any security information    (no access control list entry) is that the subscriber will not    receive the message.

This information is used to build the topic tree shown in FIG. 4.Greater complexity is typical if subscriptions with leading or embeddedwildcards are allowed (such as */stock/sell/*) but since the solution tosuch complexities is known in the art it is not necessary to describethe solution in detail here.

When a message is received at the broker with topic stringBigCorp/stock/sell/500, the matching component iteratively searches thetopic tree taking each of the components of the topic string in turn. Ina single pass of the tree, the matching component retrieves thefollowing annotations: {a,c} [Sa] {b} [Sb] {!a} [Sd]. These annotationsare then sorted by types and merged to generate consolidated lists ofrelevant subscriptions and authorized subscribers: [Sa, Sb, Sd] and {b,c}.

The broker now knows that Sa, Sb and Sd wish to receive the message andthat subscribers b and c are permitted to receive the message. Themessage is therefore sent to subscriber b only. Since the default isthat subscribers are not permitted, the lack of security information ford means that d does not receive the message.

A significant enhancement to the above-described authorization checkingfor publish/subscribe systems is to generate alerts upon occurrence ofsecurity-notifiable events, chargeable events, or other predefinedtrigger events. A first example of such events would be the failure of asecurity check—i.e. an attempt to perform an action blocked by an ACL—asshown in the flow diagram of FIG. 3B.

Since the ACLs for subscribers are stored in the repository 50 inassociation with topic names within subscriptions 40, the execution ofthe matching component 60 which evaluates which subscribers areauthorized to receive messages on a particular topic can also providethe trigger for generating an alert 370. Therefore, not only is the samematching component 60 used to perform subscription matching 340,authorization checking 350 and alert generation 370, but the very sameexecution of that matching component can be used in the performance ofall these functions.

An alert according to this embodiment of the invention comprises anidentification of the original message which resulted in rejection ofthe publication or subscription step due to the authorization check,identification of the publisher or subscriber relevant to the rejection,identification of the topic if relevant to the rejection, and anidentification of why the rejection occurred. The fields within anexample alert are shown in FIG. 5.

Unlike typical known alert or alarm systems, alerts generated by thebroker are not merely the original message being routed to a predefinedsingle administrator or application. Instead, the alerts themselves aredirected to the matching component within the broker for the matchingcomponent to determine 380 which applications should receive the alerts.Step 380 could include a separate matchspace search to identify alertsubscriptions, but in preferred embodiments a single scan of one brokersystem's matchspace can retrieve all objects required for subscriptionmatching, authorix\zation checking and for identifying relevantsubscriptions for alerts.

This allows a security application to be registered with the broker as asubscriber for alerts. Potentially the same broker and even the samematching component 60 can be used for determining the requireddissemination of an alert as was used for generating the alert inresponse to the identification of a rejected authorization check.

The generation of alerts, instead of merely adding extra subscriptionsto the original message topics, is particularly advantageous. Firstly,merely adding subscriptions suffers from the problem of whether toconform to the principle that normal subscribers do not receive anyindication of which other subscribers received or did not receive aparticular message. Registering an audit application as an additionalnormal subscriber to the original message topic will provide only a verylimited audit capability—unless additional capabilities are added andthe above principle is discarded. The present invention provides muchgreater flexibility for audit, subscription charging, and reportingalert conditions, as discussed below (and subsequently in relation toparameterized rules).

Once generated, in response to the authorization rejection, a new alertis passed to an input node of the message broker which identified theauthorization rejection. The processing of the alert to determine whichapplications should receive it can be asynchronous from the previousauthorization check, but similar attribute-based subscription matchingis performed 380. In this case, the relevant attribute is a type labelof “alert” which the message broker retrieves from the alert whenretrieving it from the broker's input node. This type label is then usedto access the relevant table of subscriptions to identify subscribersfor alerts for this topic or subscribers for all messages of type“alert”.

In alternative implementations in which different types of alert havedifferent subscribers, the type label is sufficiently specific to beassociated with a specific reason for the alert (alert1, alert2,alert3). For example, authorization-based rejection is only one of manypotential causes of alert generation. Still in a security context,alerts may be useful whenever sensitive message types are deliveredsuccessfully (as well as when rejected). Alerts may be required forgeneral audit purposes, or for usage-based charging when specific typesor topics of messages are delivered or when messages are delivered fromspecific publishers who charge for their messages.

An example implementation of alerts will now be described with referenceto FIG. 6. Referring to the example of FIG. 4, a rule #ref:S?# is addedwhich triggers generation of an alert to indicate when a request isrejected because of an ACL (either an explicit rejection instruction inthe ACL, or absence of a positive permission). The specific ruleprocedure in which this rule is coded is implemented using Prolog oranother rule based language. The alert procedure is given the followingdata as input parameters:

-   (a) the [ . . . ] subscription list;-   (b) the { . . . } ACL list; and-   (c) an identification of the interested subscriber for alerts.

The alert procedure then sends information to the subscriber-for-alertsregarding the difference between the subscription list and the ACL—forexample, denied subscribers. The interested subscriber-for-alerts willtypically not be the denied subscriber but a system administratorresponsible for authorization controls, or an audit program.

However, in certain circumstances it may be desirable to alertindividual subscribers to the fact that they are being denied access tomessages that they wish to receive. For example, the rejection could bebecause the subscribing individual has failed to renew theirsubscription renewal fees, and the alert will provide an automaticreminder.

Let us assume that Audit subscriber Sx wants to know about rejectedstock requests, but does not care about rejected announcement requests.Sx registers as a subscriber of the message broker with an associatedalert generation rule such as:

-   -   #rej:Sx#:BigCorp/stock

A topic tree is generated such as shown in FIG. 6. A single scan of thistopic tree to collect annotations will retrieve the following:

{a,c} [sa] {b} [Sb] {!a} #rej:Sx# [Sd]

The matching component of the message broker then sorts these intoannotation types and merges them to generates the lists [Sa, Sb, Sd] and{b,c} and #rej:Sx# As before, the message is sent to b only.

However, the alert procedure for rule instance #rej:Sx# is also invoked,and Sx is notified of the exceptions [Sa, Sd].

A second example implementation relates to a charging application—wheresubscribers are to be charged for messages sent to them on topicBigCorp. A different alert procedure #acc:S?# is written, implementing arule for reporting on messages actually sent to subscribers. Thecharging application Sq registers as a subscriber to the message brokerfor receiving alerts in accordance with the rule #acc:Sq#: BigCorp/*

The new generated tree 600 is shown in FIG. 7.

A single pass down the tree retrieves annotations {a,c} [Sa] {b}#acc:Sq# [Sb] {!a} #rej:Sx# [Sd]. The matching component sorts theseinto annotation types and merges them to generates the lists [Sa, Sb,Sd] and {b,c} and #acc:Sq# #rej:Sx#.

Sq is now informed by rule #acc:Sq# that [Sb] received the message.

In addition to subscriptions and ACL objects used for determiningrequired dissemination, rules procedures are also presented with otherinformation collected during the execution of the matching engine if theinformation is relevant to the particular rule. The information isstored in the broker's matchspace in association with nodes of a topictree and is presented to appropriate rules procedures as parameters tothe procedures. The list of subscribers and ACLs may be requiredparameters for an audit procedure, such that the audit procedure can usethe subscriptions and ACLs both to determine requireddissemination/processing of an alert and can use these parameters to addinformation to the alert which it sends to an interestedsubscriber-for-alerts.

Thus, according to an alternative embodiment of the invention, eachsubscription can be annotated with information to be sent with an alert.For example, assume a subscription as follows:

-   -   [Schecker]: BigCorp/stock/*−>‘rejected’+inmsg+{ }+[ ]

An authorised match on a conventional subscription will result in theoriginal message being passed to the subscriber. A parameterisedsubscription according to this embodiment will result in additionalinformation also being passed to the subscriber. In this example, thesubscriber [Schecker] will be sent the incoming message, together withthe fact that it is a ‘rejected’ message, and the { } list ofrequestors, and the [ ] ACL list. The basic match processing isunchanged from the embodiment described previously. In the previouslydescribed embodiment, the matching rule is executed at the matchingengine at the time of the match. In the ‘parameterised subscription’implementation, a message is sent with the appropriate extrainformation, and the ‘subscriber’ to this extended message processes therule asynchronously.

Nodes of the tree 600 can be annotated with values or prices as well asother parameters. As a result of a matchspace search, a value list isretrieved which indicates values of documents (based on topic orcontent). A rule implemented within the alert-processing brokerdetermines which of the values in the retrieved value list is to beapplied (for example the highest value, the sum of the values, or thelast encountered). The value to be applied is fed as an additionalparameter to any rule procedure which requires this as a parameter.

The above description of use of parameters is an additional advantageover solutions which merely add a conventional subscription to thematchspace for an audit program. A conventional subscriber would receivean original message as received by the broker, but would not receiveother associated information stored as annotations of the topic tree.Therefore, solutions which add an audit service as a conventionalsubscriber do not provide the capabilities of the parameterized ruleindication of the preferred embodiment of the present invention.

Since a single pass of the topic tree can be used to retrieve all of thedata relevant to subscription matching and alert generation, determiningwhich rules to process and which parameters to use, the presentinvention can be implemented very efficiently as an enhancement toexisting message broker software. The task of scanning the topic tree isa task that would already be required in conventional subscriptionmatching. This scanning operation is often the most costly step in termsof processing time within a typical message broker, and so thegeneration of alerts according to the present invention can beimplemented very efficiently.

The processing of rules for determining appropriate dissemination ofalerts is additional processing which is not performed by conventionalmessage brokers, and the forwarding of the alerts and subsequentprocessing for audit or charging are also additional tasks for thebroker and audit or charging applications. Nevertheless, theseadditional overheads are acceptable for the improved auditing, reportingand charging solutions that they enable.

Rules procedures may be predefined for the message broker system but, inpreferred embodiments of the invention, the broker software is adaptedto facilitate addition of further rules procedures as required. Theabove-described solution for the collection of rules to be executed fora given incoming publication is applicable to such additional ruleswhich are stored in association with nodes of the topic tree in thematchspace.

A specific implementation of the above described solution involvesextending the existing authorization features of a publish/subscribemessage broker program—extending an administration GUI and anadministration scripting interface to allow specifying of when alertsare to be generated, and what form they should take. For example, analert may include an identification of the original message,identification of the publisher or subscriber involved and the topic ifrelevant, the reason for the alert generation, and whether or not asecurity system permitted the requested action. This has a lowercommunication overhead than routing the original message to an auditservice since the information required for audit purposes could be muchsmaller than the content of the original message. An alternativeimplementation adds the new rules or extended subscriptions into thebroker system (and stores them in association with nodes of the matchingtree) by an extension of the conventional subscription mechanism.

In one alternative embodiment of the invention, the information which isoutput by a rules procedure can include the original received message—ifthis is determined to be appropriate by the specific rules procedure.This can be appropriate for some applications such as audit applicationsand security applications. However, in view of the increasedcommunication overhead if the original message is included within analert, this is generally not appropriate for a charging application. Forcharging algorithms, all that is generally required is a confirmationthat the chargeable message was sent and any required message valueinformation. In a parameterised subscriptions solution, theparameterization of the subscription will determine which details aresent to the subscriber.

In a multi-broker publish/subscribe system—which may be distributedacross a network of computers—the distribution of rules (orparameterised subscriptions) operates in a similar way to thedistribution of conventional subscriptions. Parameterised subscriptionshave increased opportunities for permitting the program codeimplementing rules for processing alerts to be located remotely from thematching code that recognised their relevance. It is also possible forthe subscriber to a parameterised subscription to be a publish/subscribematching engine. The parameterised subscription message resulting fromthe originating publication message is treated in turn as a publicationby the second publish/subscribe broker. In one example implementation,an audit service is running on a separate broker from the broker whichfirst receives a published message. The first broker generates alerts (asmall additional overhead) and sends the alerts to a second broker whichprocesses the alerts and routes them to a subscriber application such asa security application, an accounting/charging application, or a generalaudit application.

In a further example application of the invention, an SMS messagingapplication or equivalent ‘pager’ application is used to transmit alertsto warn subscribers that an important new message is awaiting action.This is an example of alerts being generated and used to warnsubscribers that high priority messages have arrived. An administratoror subscriber specifies to an alert service which message topics orpriority levels they wish to receive alerts on, a broker sends messagesto subscribers and additionally sends alerts to the alert service brokerwhich applies its own subscription/topic matching.

As indicated in the example of the last paragraph, alerts may be sentusing a different communication protocol or different quality of servicefrom normal messages. For example, duplicates may not be a problem forsome alerts (perhaps the alert must be received immediately or is of novalue) whereas in an audit trail solution the speed of delivery may beof little importance but assured once-only delivery may be arequirement. The choice of communication protocol may be made by theimplementation of the rules procedure when the alert is controlled by arule invoked locally to the matching engine. Alternatively, in aparameterised subscriptions solution, the topic tree can be annotatedwith protocol details and the appropriate communication protocol is aninput to the rules procedure. This capability can be implemented as arelatively simple extension to certain existing systems in which thereis already an ability to choose distribution details (protocol orpersistence) in association with ordinary subscriptions.

1. A data processing apparatus for providing a publish/subscribe messagedissemination service on behalf of publisher and subscriber programscomprising: means for receiving a published message from a publisherprogram; means, responsive to identification of one or more messagesubscriber programs subscribing to messages of the type of the receivedmessage, for forwarding the received message to the one or more messagesubscriber programs; and one or more matcher components for: comparingthe received message with stored message subscriptions to identify theone or more message subscriber programs; generating an alert when analert condition is satisfied; and comparing the generated alert withstored alert subscriptions to identify one or more subscriber programssubscribing to the alert; and means for forwarding the alert to the oneor more subscriber programs subscribing to the alert, wherein themessage and alert subscriptions are stored in data storage inassociation with message topic information, the one or more matchercomponents including means for retrieving stored subscriptioninformation by reference to message topic information of a receivedmessage, rules procedures for generating and determining requireddissemination of alerts are stored in association with the message topicinformation, wherein the one or more matcher components are adapted toidentify a relevant rules procedure by reference to the message topicinformation and to forward to the identified rules procedure: a messagesubscription list; a list of authorized recipients; and anidentification of one or more subscribers for alerts; thereby to enablegeneration and determination of required dissemination of an alert; theone or more matcher components includes: means for performing anauthorization check to identify a subset of the identified one or moremessage subscriber programs which subset of programs is authorized toreceive the message; and means for generating an alert when theauthorization check identifies an unauthorized message subscriber.